In our modern communications age, commercial enterprises, consumers, and other entities are storing an ever increasing amount of digitized data. For example, many entities are in the process of digitizing their business records and/or other data. Similarly, web based service providers generally engage in transactions that are primarily digital in nature. Thus, techniques and mechanisms that facilitate efficient and cost effective storage of vast amounts of digital data are being implemented.
In some modern data storage systems, data is formatted or organized as a file so that it can be stored within file systems and/or volumes. Since the data is digital or “digitized” (e.g., stored as bits of either 0 or 1), one or more (backup) copies of the data can be made relatively easily. When a copy of a data file is made, the original file is at times referred to as the parent while the copy may be referred to as the child, where the child is a lossless (e.g., bit for bit) snapshot or “picture” of the parent data taken at a particular point in time. Similarly, in such a scenario, the original file may be regarded as residing on or being stored within a parent volume while the copy may be regarded as residing on or being stored within a child volume, where a volume generally corresponds to an amount of memory allocated for storing the data file.
It can be appreciated that in some situations it may be advantageous and/or otherwise desirable to maintain a copy of the data as it appeared at some point in time (e.g., as depicted in the parent volume), while also being able to perform testing and/or other operations upon the data as it appeared at that same point in time (e.g., as depicted in a child volume), where such testing or other operations may occur at the same and/or one or more later points in time.
In order to provide for this functionality, data storage systems have evolved to include flexible copy volumes, which effectively store children files of a parent file. That is, a child or snapshot copy of a parent data file can be stored on a flexible copy volume such that the child file can be manipulated and/or otherwise modified (e.g., for data verification, product/system development, testing, bug fixing, upgrade checks, data set simulations, etc.) without affecting the parent data file.
It can be appreciated that establishing different flexible copy volumes such that they, or rather the (child) data stored therein, can be operated on by merely the same or a single set of operations can constrain the usefulness and/or robustness of such flexible copy volumes. For example, with such a limited set of operations available for application to flexible copy volumes, a user may be prone to keep multiple snapshots of the data (possibly taken at different points in time) in an attempt to observe one or more trends, for example, as one or more of the predefined operations are repeatedly applied to the data. It will be appreciated, however, that this is just one of any number of examples where the inflexibility afforded by having the same set of operations available to apply to different flexible copy volumes may cause and/or otherwise encourage a user to maintain a large number of flexible copy volumes (e.g., not deleting them in a timely manner). However, since respective flexible copy volumes require some resources (e.g., physical memory), maintaining a large number of flexible copy volumes can (undesirably) consume a large amount of resources.